BTIC
BTIC is a family of specialized video codecs. Naming: * BTICxy or BTICxyz ** x (digit) is the family. ** y (letter) is the particular codec. ** z (digit) if included, is a major version (breaking changes). Some Theory: * Efficiency and Blocky VQ BT_FastVQ BTIC1x family: * Used for speed-oriented blocky VQ codecs. * BTIC1A and BTIC1B ** Were very fast, but had horrible compression. ** Had started as experiments to pack / LZ-compress DXT1 and DXT5. * BTIC1C ** First generally successful design. ** Based initially on Apple Video / RPZA. ** Hacked/extended significantly to improve image quality and compression. * BTIC1D ** Used similar technology to 1C, but was based on YUV & 4:2:0 chroma subsampling. ** It was neither good nor fast. Bitrate was poor, codec speed was lackluster. *** And was not readily convertible to DXTn or BCn. ** Loosely similar technology was later added to 1C. ** BTIC1G and BTIC1H also are based around similar technology for some blocks. ** One difference was that it had stored UV ranges and had interpolated all 3. *** Ex: block had 48 bits pixel data, 32 for Y and 16 for U&V (2x 2x2x2bpp). *** Could possibly be added to BTIC1H (YUVDyuv 4:2:0). * BTIC1E ** Design, never implemented as I soon realized it would suck really hard. ** Was based on byte-slicing BC7 blocks. ** Speed and compression were likely to be worse than merely using Deflate compression on BC6H or BC7. * BTIC1F ** Initial results looked promising, but never fully implemented. ** Split color and pixel data into separate buffers. ** Color data was akin to a command-based lossy PNG. ** Problem domain had moved, and the design had limitations. *** Multiple planar buffers was problematic. *** Design would not have been well suited to incremental compression. * BTIC1G ** Was designed with an emphasis on low implementation complexity and incremental encoding. ** Used YUV partly because the image-sensor data is available as YUV (or Bayer). ** Didn't use entropy coding partly for speed. *** Raspberry Pi doesn't have super powerful CPU. *** Can't currently make much use of VideoCore. **** Console operation, very latency sensitive, UDP-based communication, ... **** This hindered use of more traditional codecs. ***** Would need a larger latency window and to use TCP. * BTIC1H ** Based mostly on BTIC1G and BTIF1F. ** Unique in that it uses AdRice coding instead of Deflate or BTLZH coding. ** Mostly this is for better supporting incremental encoding. *** Huffman is generally better on both the speed and compression front. *** However, AdRice is better able to exploit specialized contexts vs Huffman. *** Given UDP, can't ensure messages arrive or in correct order, making Huff problematic. **** Constant overhead for static Huffman is also not good for small messages. **** Vitter was slower and compressed worse in prior experiments than AdRice. ** Generally, compression is better but decode speed is worse than BTIC1C. BTIC2x family: * BTIC2A / BTIC2B ** Too complex to be easily implemented, gave up. * BTIC2C ** Essentially JPEG-like design with some tweaks and similar. *** Basic motion compensation and differential coding in P-Frames. ** Was intended for high decode speed, but results were lackluster here. ** Can do high-quality or lossless video though at a sane bitrate. *** However, encode speed is too slow to be viable for screen capture. *** I have generally used BTIC1C or BTIC1H for PC screen-capture. **** My PC is too slow to get good results with more traditional options/codecs. * BTIC2D ** Was an attempt at a high-speed DCT-based design. ** Was not able to sufficiently outperform BTIC2C or M-JPEG to be worthwhile. ** It had made use of asymmetric Y and UV blocks, rather than solely 8x8 blocks. *** Ex: 4x4+2x 2x2 or 8x8+ 2x 4x4. *** This led to a smaller macroblock size. ** While the DCT was cheaper, entropy coding/... was more expensive. *** Blocks had far fewer zeroes, ... BTIC3x family: * Attempts to combine DCT and VQ technology. * Thus far nothing in this group has been effective. ** Most designs become excessively complicated. ** Compression does not generally outperform BTIC1x designs. ** Can use mixed 1x and 2C or JPEG (Say, JPG I-Frame and 1C or 1H P-Frames). *** Limited effectiveness for the issues this introduces. *** This is detrimental to codec speeds. *** For I-Frames, 1H isn't drastically worse than JPEG.